home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / html / rfc / rfcxxxx / rfc1103 < prev    next >
Text File  |  1995-07-25  |  19KB  |  507 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                            D. Katz
  8. Request for Comments:  1103                                 Merit/NSFNET
  9.                                                                June 1989
  10.  
  11.               A Proposed Standard for the Transmission of
  12.                     IP Datagrams over FDDI Networks
  13.  
  14.  
  15. Status of this Memo
  16.  
  17.    This RFC specifies a method of encapsulating the Internet Protocol
  18.    (IP) [1] datagrams and Address Resolution Protocol (ARP) [2] requests
  19.    and replies on Fiber Distributed Data Interface (FDDI) Networks.
  20.    This RFC specifies a proposed protocol standard for the Internet
  21.    community.  Comments are welcome.  Distribution of this memo is
  22.    unlimited.
  23.  
  24. Acknowledgment
  25.  
  26.    This memo draws heavily in both concept and text from RFC 1042 [3],
  27.    written by Jon Postel and Joyce K. Reynolds of USC/Information
  28.    Sciences Institute.
  29.  
  30. Conventions
  31.  
  32.    The following language conventions are used in the items of
  33.    specification in this document:
  34.  
  35.       "Must" or "Mandatory"--the item is an absolute requirement of the
  36.       specification.
  37.  
  38.       "Should" or "Recommended"--the item should generally be followed
  39.       for all but exceptional circumstances.
  40.  
  41.       "May" or "Optional"--the item is truly optional and may be
  42.       followed or ignored according to the needs of the implementor.
  43.  
  44. Introduction
  45.  
  46.    The goal of this specification is to allow compatible and
  47.    interoperable implementations for transmitting IP datagrams and ARP
  48.    requests and replies.
  49.  
  50.    The Fiber Distributed Data Interface (FDDI) specifications define a
  51.    family of standards for Local Area Networks (LANs) that provides the
  52.    Physical Layer and Media Access Control Sublayer of the Data Link
  53.    Layer as defined by the ISO Open System Interconnection Reference
  54.    Model (ISO/OSI).  Documents are in various stages of progression
  55.  
  56.  
  57.  
  58. Katz                                                            [Page 1]
  59.  
  60. RFC 1103            IP Datagrams over FDDI Networks            June 1989
  61.  
  62.  
  63.    toward International Standardization for Media Access Control (MAC)
  64.    [4], Physical Layer Protocol (PHY) [5], Physical Layer Medium
  65.    Dependent (PMD) [6], and Station Management (SMT) [7].  The family of
  66.    FDDI standards corresponds to the IEEE 802 MAC layer standards [8, 9,
  67.    10].
  68.  
  69.    The remainder of the Data Link Service is provided by the IEEE 802.2
  70.    Logical Link Control (LLC) service [11].  The resulting stack of
  71.    services appears as follows:
  72.  
  73.            +-------------+
  74.            |   IP/ARP    |
  75.            +-------------+
  76.            |  802.2 LLC  |
  77.            +-------------+
  78.            |  FDDI MAC   |
  79.            +-------------+
  80.            |  FDDI PHY   |
  81.            +-------------+
  82.            |  FDDI PMD   |
  83.            +-------------+
  84.  
  85.    This memo describes the use of IP and ARP in this environment.  At
  86.    this time, it is not necessary that the use of IP and ARP be
  87.    consistent between FDDI and IEEE 802 networks, but it is the intent
  88.    of this memo not to preclude Data Link Layer interoperability at such
  89.    time as the standards define it.
  90.  
  91. Packet Format
  92.  
  93.    IP datagrams and ARP requests and replies sent on FDDI networks must
  94.    be encapsulated within the 802.2 LLC and Sub-Network Access Protocol
  95.    (SNAP) data link layers and the FDDI MAC and physical layers.  The
  96.    SNAP must be used with an Organization Code indicating that the SNAP
  97.    header contains the EtherType code (as listed in Assigned Numbers
  98.    [12]).
  99.  
  100.    802.2 LLC Type 1 communication (which must be implemented by all
  101.    conforming 802.2 stations) is used exclusively.  All frames must be
  102.    transmitted in standard 802.2 LLC Type 1 Unnumbered Information
  103.    format, with the DSAP and the SSAP fields of the 802.2 header set to
  104.    the assigned global SAP value for SNAP [11].  The 24-bit Organization
  105.    Code in the SNAP must be zero, and the remaining 16 bits are the
  106.    EtherType from Assigned Numbers [12] (IP = 2048, ARP = 2054).
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Katz                                                            [Page 2]
  115.  
  116. RFC 1103            IP Datagrams over FDDI Networks            June 1989
  117.  
  118.  
  119.      ...--------+--------+--------+
  120.                 MAC Header        |                           FDDI MAC
  121.      ...--------+--------+--------+
  122.  
  123.      +--------+--------+--------+
  124.      | DSAP=K1| SSAP=K1| Control|                            802.2 LLC
  125.      +--------+--------+--------+
  126.  
  127.      +--------+--------+---------+--------+--------+
  128.      |Protocol Id or Org Code =K2|    EtherType    |        802.2 SNAP
  129.      +--------+--------+---------+--------+--------+
  130.  
  131.      The total length of the LLC Header and the SNAP header is 8
  132.      octets.
  133.  
  134.      The K1 value is 170 (decimal).
  135.  
  136.      The K2 value is 0 (zero).
  137.  
  138.      The control value is 3 (Unnumbered Information).
  139.  
  140. Address Resolution
  141.  
  142.    The mapping of 32-bit Internet addresses to 16-bit or 48-bit FDDI
  143.    addresses must be done via the dynamic discovery procedure of the
  144.    Address Resolution Protocol (ARP) [2].
  145.  
  146.    Internet addresses are assigned arbitrarily on Internet networks.
  147.    Each host's implementation must know its own Internet address and
  148.    respond to Address Resolution requests appropriately.  It must also
  149.    use ARP to translate Internet addresses to FDDI addresses when
  150.    needed.
  151.  
  152.    The ARP protocol has several fields that parameterize its use in any
  153.    specific context [2].  These fields are:
  154.  
  155.          hrd   16 - bits     The Hardware Type Code
  156.          pro   16 - bits     The Protocol Type Code
  157.          hln    8 - bits     Octets in each hardware address
  158.          pln    8 - bits     Octets in each protocol address
  159.          op    16 - bits     Operation Code
  160.  
  161.    The hardware type code assigned for IEEE 802 networks is 6 [12].
  162.    FDDI networks, although not IEEE 802 networks per se, are
  163.    semantically equivalent and use the same type code.
  164.  
  165.    The protocol type code for IP is 2048 [12].
  166.  
  167.  
  168.  
  169.  
  170. Katz                                                            [Page 3]
  171.  
  172. RFC 1103            IP Datagrams over FDDI Networks            June 1989
  173.  
  174.  
  175.    The hardware address length is 2 for 16-bit FDDI addresses, or 6 for
  176.    48-bit FDDI addresses.
  177.  
  178.    The protocol address length (for IP) is 4.
  179.  
  180.    The operation code is 1 for request and 2 for reply.
  181.  
  182. Broadcast Address
  183.  
  184.    The broadcast Internet address (the address on that network with a
  185.    host part of all binary ones) must be mapped to the broadcast FDDI
  186.    address (of all binary ones) (see [13]).
  187.  
  188. Trailer Formats
  189.  
  190.    Some versions of Unix 4.x bsd use a different encapsulation method in
  191.    order to get better network performance with the VAX virtual memory
  192.    architecture.  Consenting systems on the same FDDI network may use
  193.    this format between themselves.  Details of the trailer encapsulation
  194.    method may be found in [14].  However, all hosts must be able to
  195.    communicate using the standard (non-trailer) method.
  196.  
  197. Byte Order
  198.  
  199.    As described in Appendix B of the Internet Protocol specification
  200.    [1], the IP datagram is transmitted over FDDI networks as a series of
  201.    8-bit bytes.  This byte transmission order has been called "big-
  202.    endian" [15].
  203.  
  204. MAC Layer Details
  205.  
  206.    Packet Size
  207.  
  208.       The FDDI MAC specification [4] defines a maximum frame size of
  209.       9000 symbols (4500 octets) for all frame fields, including four
  210.       symbols (two octets) of preamble.  This gives the following MAC
  211.       layer overhead:
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Katz                                                            [Page 4]
  227.  
  228. RFC 1103            IP Datagrams over FDDI Networks            June 1989
  229.  
  230.  
  231.                 Field                    Size in Octets
  232.  
  233.                 Preamble                     2
  234.                 Start Delimiter              1
  235.                 Frame Control                1
  236.                 Destination Address          6 (2)
  237.                 Source Address               6 (2)
  238.                 FCS                          4
  239.                 End Delimiter/Frame Status   2
  240.  
  241.                 Total                        22 (14)
  242.                 Remaining for Data           4478 (4486)
  243.  
  244.       Subtracting the 8 byte LLC/SNAP header, this gives a maximum
  245.       packet size (MTU) of 4470 (4478) octets.  For compatibility
  246.       purposes, the maximum packet size used with IP datagrams or ARP
  247.       requests and replies must be consistent on a particular network.
  248.  
  249.       The overhead calculations (above) assume a standard Frame Status
  250.       field consisting of three symbols.  Additional Implementor Defined
  251.       frame status information, although permitted by the FDDI MAC
  252.       specification, must not be used with IP datagrams because it
  253.       affects the maximum packet size.
  254.  
  255.       Gateway implementations must be prepared to accept full-length
  256.       packets and fragment them when necessary.
  257.  
  258.       Host implementations should be prepared to accept full-length
  259.       packets; however, hosts must not send datagrams longer than 576
  260.       octets unless they have explicit knowledge that the destination is
  261.       prepared to accept them.  A host may communicate its size
  262.       preference in TCP-based applications via the TCP Maximum Segment
  263.       Size option [16].
  264.  
  265.       Datagrams on FDDI networks may be longer than the general Internet
  266.       default maximum packet size of 576 octets.  Hosts connected to an
  267.       FDDI network should keep this in mind when sending datagrams to
  268.       hosts that are not on the same local network.  It may be
  269.       appropriate to send smaller datagrams to avoid unnecessary
  270.       fragmentation at intermediate gateways.  Please see [16] for
  271.       further information.
  272.  
  273.       There is no minimum packet size restriction on FDDI networks.
  274.  
  275. Other MAC Layer Issues
  276.  
  277.    The FDDI MAC specification does not require that 16-bit and 48-bit
  278.    address stations be able to interwork fully.  It does, however,
  279.  
  280.  
  281.  
  282. Katz                                                            [Page 5]
  283.  
  284. RFC 1103            IP Datagrams over FDDI Networks            June 1989
  285.  
  286.  
  287.    require that 16-bit stations have full 48-bit functionality, and that
  288.    both types of stations be able to receive frames sent to either size
  289.    broadcast address.  For use with IP and ARP, all communicating
  290.    stations on a LAN must use a consistent address size.
  291.    Implementations must discard any IP or ARP packets received with an
  292.    unimplemented or inactive address size.  16-bit and 48-bit
  293.    implementations may coexist on the same FDDI network; however, if
  294.    they wish to interwork they must be considered separate IP networks
  295.    and linked with an IP router capable of supporting 16-and 48-bit
  296.    addresses simultaneously.
  297.  
  298.    Group (multicast) addresses are defined by the FDDI MAC specification
  299.    but are not necessarily supported by existing hardware.  Therefore,
  300.    this feature must not be used by IP and ARP.
  301.  
  302.    The FDDI MAC specification defines two classes of frames,
  303.    Asynchronous and Synchronous.  Asynchronous frames are further
  304.    controlled by a priority mechanism and two classes of token,
  305.    Restricted and Unrestricted.  Only the use of Unrestricted tokens and
  306.    Asynchronous frames are required by the standard for FDDI
  307.    interoperability.  The priority mechanism is currently implemented
  308.    locally by the transmitting station and the Priority field in
  309.    Asynchronous frames is ignored by other stations.  This field will
  310.    likely be interpreted by Transparent Bridges once they are defined.
  311.    There is no default value for priority called out in the MAC
  312.    standard.
  313.  
  314.    Therefore, all IP and ARP frames must be transmitted as Asynchronous
  315.    frames using Unrestricted tokens, and the Priority value is a matter
  316.    of local convention.  Implementations should make the priority a
  317.    tunable parameter for future use.  It is recommended that
  318.    implementations provide for the reception of IP and ARP packets in
  319.    Synchronous frames.
  320.  
  321.    After packet transmission, FDDI provides Frame Copied (C) and Address
  322.    Recognized (A) indicators.  There are four possible combinations of
  323.    the indicators with the following semantics:
  324.  
  325.             (C)      (A)
  326.             Reset    Reset   The frame was not received by any station.
  327.             Reset    Set     The addressed station is congested.
  328.             Set      Reset   Reserved.
  329.             Set      Set     The addressed station received the frame.
  330.  
  331.    Implementations may use these indicators to provide some amount of
  332.    error detection and correction:
  333.  
  334.       If the Frame Copied bit is reset but the Address Recognized bit is
  335.  
  336.  
  337.  
  338. Katz                                                            [Page 6]
  339.  
  340. RFC 1103            IP Datagrams over FDDI Networks            June 1989
  341.  
  342.  
  343.       set, receiver congestion has occurred.  It is recommended, though
  344.       not mandatory, that hosts retransmit the offending packet a small
  345.       number of times (4) or until congestion no longer occurs.
  346.  
  347.       If the both the Address Recognized indicator and the Frame Copied
  348.       indicator are reset, an implementation has three options: (1)
  349.       ignore the error and throw the packet away, (2) return an ICMP
  350.       destination unreachable message to the source, or (3) delete the
  351.       ARP entry which was used to send this packet and send a new ARP
  352.       request to the destination address.  The latter option is the
  353.       preferred approach since it will allow graceful recovery from
  354.       first hop bridge and router failures and changed hardware
  355.       addresses.
  356.  
  357.       As of this writing there is a proposal within ANSI to set the
  358.       Frame Copied indicator and reset the Address Recognized indicator
  359.       when a frame is forwarded by a Transparent Bridge.  For future
  360.       compatibility, implementations should interpret this combination
  361.       of indicators as if the frame were successfully delivered to the
  362.       destination (i.e., do nothing).
  363.  
  364. IEEE 802.2 Details
  365.  
  366.    While not necessary for supporting IP and ARP, all implementations
  367.    must support IEEE 802.2 standard Class I service in order to be
  368.    compliant with 802.2.  This requires supporting Unnumbered
  369.    Information (UI) Commands, eXchange IDentification (XID) Commands and
  370.    Responses, and TEST link (TEST) Commands and Responses.
  371.  
  372.    When an XID or TEST command is received, a response must be returned
  373.    with Destination and Source addresses, and DSAP and SSAP, swapped.
  374.  
  375.    When responding to an XID or a TEST command, the value of the Final
  376.    bit in the response must be copied from the value of the Poll bit in
  377.    the command.
  378.  
  379.    The XID command or response has an LLC control field value of 175
  380.    (decimal) if the Poll/Final bit is off or 191 (decimal) if the
  381.    Poll/Final bit is on.
  382.  
  383.    The TEST command or response has an LLC control field value of 227
  384.    (decimal) if the Poll/Final bit is off or 243 (decimal) if the
  385.    Poll/Final bit is on.
  386.  
  387.    Command frames are identified by having the high order bit of the
  388.    SSAP address reset to zero.  Response frames have the high order bit
  389.    of the SSAP address set to one.
  390.  
  391.  
  392.  
  393.  
  394. Katz                                                            [Page 7]
  395.  
  396. RFC 1103            IP Datagrams over FDDI Networks            June 1989
  397.  
  398.  
  399.    XID response frames must include an 802.2 XID Information field of
  400.    129.1.0 indicating Class I (connectionless) service.
  401.  
  402.    TEST response frames must echo the information field received in the
  403.    corresponding TEST command frame.
  404.  
  405. Appendix on Numbers
  406.  
  407.    The IEEE specifies numbers in bit transmission order, or bit-wise
  408.    little-endian order.  The Internet protocols are documented in byte-
  409.    wise big-endian order.  This may cause some confusion about the
  410.    proper values to use for numbers.  Here are the conversions for some
  411.    numbers of interest.
  412.  
  413.        Number        IEEE    IEEE        Internet    Internet
  414.                      HEX     Binary      Binary      Decimal
  415.  
  416.        UI Op Code    C0      11000000    00000011    3
  417.        SAP for SNAP  55      01010101    10101010    170
  418.        XID           F5      11110101    10101111    175
  419.        XID           FD      11111101    10111111    191
  420.        TEST          C7      11000111    11100011    227
  421.        TEST          CF      11001111    11110011    243
  422.        Info          818000                          129.1.0
  423.  
  424. References
  425.  
  426.   [1]  Postel, J., "Internet Protocol", RFC-791, USC/Information
  427.        Sciences Institute, September 1981.
  428.  
  429.   [2]  Plummer, D., "An Ethernet Address Resolution Protocol - or -
  430.        Converting Network Protocol Addresses to 48.bit Ethernet Address
  431.        for Transmission on Ethernet Hardware", RFC-826, MIT, November
  432.        1982.
  433.  
  434.   [3]  Postel J., and J. Reynolds, "A Standard for the Transmission of
  435.        IP Datagrams over IEEE 802 Networks", RFC1042, USC/Information
  436.        Sciences Institute, February, 1988.
  437.  
  438.   [4]  ISO, "Fiber Distributed Data Interface (FDDI) - Media Access
  439.        Control", ISO 9314-2, 1988.  See also ANSI X3.139-1987.
  440.  
  441.   [5]  ISO, "Fiber Distributed Data Interface (FDDI) - Token Ring
  442.        Physical Layer Protocol", ISO 9314-1, 1988.  See also ANSI
  443.        X3.148-1988.
  444.  
  445.   [6]  ISO, "Fiber Distributed Data Interface (FDDI) - Physical Layer
  446.        Medium Dependent", ISO DIS 9314-3, 1988.  See also ANSI X3.166-
  447.  
  448.  
  449.  
  450. Katz                                                            [Page 8]
  451.  
  452. RFC 1103            IP Datagrams over FDDI Networks            June 1989
  453.  
  454.  
  455.        198x.
  456.  
  457.   [7]  ANSI, "FDDI Station Management", ANSI X3T9.5/84-49 Rev 4.0, 1988.
  458.  
  459.   [8]  IEEE, "IEEE Standards for Local Area Networks: Carrier Sense
  460.        Multiple Access with Collision Detection (CSMA/CD) Access Method
  461.        and Physical Layer Specifications", IEEE, New York, New York,
  462.        1985.
  463.  
  464.   [9]  IEEE, "IEEE Standards for Local Area Networks: Token-Passing Bus
  465.        Access Method and Physical Layer Specification", IEEE, New York,
  466.        New York, 1985.
  467.  
  468.   [10] IEEE, "IEEE Standards for Local Area Networks: Token Ring Access
  469.        Method and Physical Layer Specifications", IEEE, New York, New
  470.        York, 1985.
  471.  
  472.   [11] IEEE, "IEEE Standards for Local Area Networks: Logical Link
  473.        Control", IEEE, New York, New York, 1985.
  474.  
  475.   [12] Reynolds, J.K., and J. Postel, "Assigned Numbers", RFC-1010,
  476.        USC/Information Sciences Institute, May 1987.
  477.  
  478.   [13] Braden, R., and J. Postel, "Requirements for Internet Gateways",
  479.        RFC-1009, USC/Information Sciences Institute, June 1987.
  480.  
  481.   [14] Leffler, S., and M. Karels, "Trailer Encapsulations", RFC-893,
  482.        University of California at Berkeley, April 1984.
  483.  
  484.   [15] Cohen, D., "On Holy Wars and a Plea for Peace", Computer, IEEE,
  485.        October 1981.
  486.  
  487.   [16] Postel, J., "The TCP Maximum Segment Size Option and Related
  488.        Topics", RFC-879, USC/Information Sciences Institute, November
  489.        1983.
  490.  
  491. Author's Address
  492.  
  493.    Dave Katz Merit/NSFNET 1075 Beal Ann Arbor, MI 48109-2112
  494.  
  495.    Phone: 1-800-66-MERIT
  496.  
  497.    Email: Dave_Katz@um.cc.umich.edu
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Katz                                                            [Page 9]
  507.